Security Management in the Cloud - SaaS Availability Management

Uptime Goal—NetSuite commits to provide 99.5% uptime with respect to the NetSuite application, excluding regularly scheduled maintenance times.

Scheduled and Unscheduled Maintenance—Regularly scheduled maintenance time does not count as downtime. Maintenance time is regularly scheduled if it is communicated at least two full business days in advance of the maintenance time. Regularly scheduled maintenance time typically is communicated at least a week in advance, scheduled to occur at night on the weekend, and takes less than 10–15 hours each quarter.

NetSuite hereby provides notice that every Saturday night 10:00pm–10:20pm Pacific Time is reserved for routine scheduled maintenance for use as needed.

Here is another SLA example:

During the Term of the applicable Google Apps Agreement, the Google Apps Covered Services web interface will be operational and available to Customer at least 99.9% of the time in any calendar month (the “Google Apps SLA”). If Google does not meet the Google Apps SLA, and if Customer meets its obligations under this Google Apps SLA, Customer will be eligible to receive the Service Credits described below. This Google Apps SLA states Customer’s sole and exclusive remedy for any failure by Google to provide the Service.

Monthly Uptime Percentage	Days of Service added to the end of the Service term, at no charge to Customer
< 99.9% – ≥ 99.0%	3
< 99.0% – ≥ 95.0%	7
< 95.0%	15

Customer Must Request Service Credit. In order to receive any of the Service Credits described above, Customer must notify Google within thirty days from the time Customer becomes eligible to receive a Service Credit. Failure to comply with this requirement will forfeit Customer’s right to receive a Service Credit.

Maximum Service Credit. The aggregate maximum number of Service Credits to be issued by Google to Customer for any and all Downtime Periods that occur in a single calendar month shall not exceed fifteen days of Service added to the end of Customer’s term for the Service. Service Credits may not be exchanged for, or converted to, monetary amounts.

Google Apps SLA Exclusions. The Google Apps SLA does not apply to any services that expressly exclude this Google Apps SLA (as stated in the documentation for such services) or any performance issues: (i) caused by factors outside of Google’s reasonable control; or (ii) that resulted from Customer’s equipment or third party equipment, or both (not within the primary control of Google).

There is no such thing as standard SLA among cloud service providers. Uptime guarantee, service credits, and service exclusions clauses will vary from provider to provider.

1. Customer Responsibility

Customers should understand the SLA and communication methods (e.g., email, RSS feed, website URL with outage information) to stay informed on service outages. When possible, customers should use automated tools such as Nagios or Siteuptime.com to verify the availability of the SaaS service.

As of this writing, customers of a SaaS service have a limited number of options to support availability management. Hence, customers should seek to understand the availability management factors, including the SLA of the service, and clarify with the CSP any gaps in SLA exclusions and service credits when disruptions occur. In a recently published white paper by the U.S.-based Software & Information Industry Association (SIIA), the efficacy of SaaS SLAs was analyzed in the context of software vendors moving to a SaaS delivery model. The paper concluded that certain elements are necessary to make the SLA an effective document, and states that:

Communication and clear expectations are required from both the service provider and their customers to identify what is important and realistic with respect to standards and expectations.

Customers of cloud services should note that a multitenant service delivery model is usually designed with a “one size fits all” operating principle, which means CSPs typically offer a standard SLA for all customers. Thus, CSPs may not be amenable to providing custom SLAs if the standard SLA does not meet your service-level requirements. However, if you are a medium or large enterprise with a sizable budget, a custom SLA may still be feasible.

Since most SaaS providers use virtualization technologies to deliver a multitenant service, customers should also understand how resource democratization occurs within the CSP to best predict the likelihood of system availability and performance during business fluctuations. If the resources (network, CPU, memory, storage) are not allocated in a fair manner across the tenants to perform the workload, it is conceivable that a highly demanding tenant may starve other tenants, which can result in lower service levels or poor user experience.

2. SaaS Health Monitoring

The following options are available to customers to stay informed on the health of their service:

• Service health dashboard published by the CSP. Usually SaaS providers, such as Salesforce.com, publish the current state of the service, current outages that may impact customers, and upcoming scheduled maintenance services on their website (e.g., http://trust.salesforce.com/trust/status/).

• The Cloud Computing Incidents Database (CCID). (This database is generally community-supported, and may not reflect all CSPs and all incidents that have occurred.)

• Customer mailing list that notifies customers of occurring and recently occurred outages.

• Internal or third-party-based service monitoring tools that periodically check SaaS provider health and alert customers when service becomes unavailable (e.g., Nagios monitoring tool).

• RSS feed hosted at the SaaS service provider.